|
|
|
|
|
|
|
As with Web applications, unattended application sessions are also a potential security problem for desktop applications. For these desktop applications, you would enforce unattended session policies by, among other ways, using the Timer control in conjunction with placing code in the events associated with text box changes and mouse clicks. As with the Web application, you could implement the same class, SessionAuditor. |
|
|
|
|
|
|
|
|
Sabotage is also a problem. Disgruntled employees will exploit weaknesses and errors in your application to get revenge on a boss or for some slight they experienced. Further, forcing users to use a system that is either flawed or, for reasons unknown to you, undesirable, only exaggerates the problem. In a paper titled A Case of Sabotage, by Peter Bickford, from Human Interface, the author captures the sentiment of some users of workgroup-oriented, corporate applications as follows: |
|
|
|
 |
|
|
|
|
Even if you assign every user in your company a login ID and tell them they're absolutely required to use the system, you're unlikely to get the results you want if users aren't also convinced of the benefit (to them) of following your directives. At best, you'll end up with users who do only the minimum required of them and never use the full capabilities of the system. Worse, they may use passive resistance to thwart the system: Well, gee, I keep meaning to enter my project information, but I've been too busy with more important things. Some users may even engage in acts of outright sabotage, such as padding the figures they enter in the system or deliberately blocking out all the free space in their workgroup calendar to prevent others from scheduling their time. |
|
|
|
|
|
|
|
|
You can minimize security threats posed by sabotage by, at a minimum, including users in the design of the architecture of the system, and in particular the behavior of the various workgroups. Without effective executive sponsorship, however, such efforts may be difficult. |
|
|
|
|
|
|
|
|
Concepts of Workgroups and Workflow |
|
|
|
|
|
|
|
|
Workflow automation involves the coordination of often complex business processes. The simplest business processes that you may automate with Visual Basic may require much flexibility as your clients' infrastructure changes dynamically, requiring an adaptation to changing conditions. Whether you're developing a Visual Basic application for a large enterprise on site at the company or as a commercial operation that markets and sells software systems, the modeling of any workgroup architecture with workflows is never an easy task. In the most sophisticated multinational corporations, workflow architects and administrators have to concern themselves with issues involving the following: |
|
|
|
|
|
|
|
|
Parallel routing of tasks between workgroups (and roles within those workgroups) |
|
|
|
|
|
|
|
|
Evolving workgroup structures |
|
|
|
|
|